Hi! I dropped the f-strings commit.

The Flake8 Bugbear warnings also come from files I didn't touch, because the CI is using unpinned versions and B028 is a new check released yesterday:

https://github.com/PyCQA/flake8-bugbear/releases/tag/23.1.14

(I use pre-commit for pinning, running and updating linters.)

Oh, I see. Not pinning the version here in the GitPython CI has led to unpleasant surprises more than once. Would you be able to adjust the workflow file to install a specific (the previous) version of it and fix CI that way? Maybe the code for that is already present in the hooks you are using.

Updated to move linting out of the Cygwin and Ubuntu workflows and into a dedicated workflow: this makes it clearer if the CI fails due to linting or a test failure. And there's no need to run linting on every Python version and OS.

To run the linting locally:

# Install the tool
python -m pip install pre-commit

# Lint all the files, only those in Git
pre-commit run --all-files

You can also install it to run when you commit, and it only checks those staged commits. This is entirely optional, the CI will do its checks anyway, and you can run the above commands at any time.

pre-commit install

Then commit as normal, and it will first run the lint. If it find problems, it will stop and halt the commit before completing. You then get to check the problems, make changes, and try the commit again. One benefit is "fail fast", you find errors before pushing.

If you change your mind:

pre-commit uninstall

And can still run manually via pre-commit run --all-files or let the CI deal with it.

By the way, I saw on your profile that this quality of work doesn't come from nothing. Is Co-Maintaining GitPython an option for you? I really am not doing a good job as I have not caught up with Python which I stopped using entirely what feels like 10 years ago. Thanks for your consideration.

Hi, thanks for the offer, however my open-source plate is a little full at the moment.